1. Technical Field
This invention generally relates to computer systems, and more specifically relates to an apparatus and method for measuring transaction time in a computer system.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different environments. Since the dawn of the computer age, the performance of computers has been measured to determine how well the computer performs certain tasks. One measure of computer performance is response time, which is used herein to broadly define the time it takes the computer to perform a specific task or transaction. Generally, the response time that is of most interest is the user-perceived response time. For a single user on a single stand-alone computer system, the user-perceived response time is virtually the same as the time it takes the computer to perform the desired task or transaction. However, as multiple users and computers are added, the user-perceived response time is different than the processing time for the task on a single computer.
In the early days of computers, one or more relatively powerful and expensive computers could be shared by many users. Referring to FIG. 1, a number of computer terminals 130 were typically connected to a single computer 110 known as a "host." These computer terminals 130 are commonly known as non-programmable workstations (i.e., "dumb terminals") because they simply display information transmitted to it by the host, and lack any processing power to perform local tasks. One example of a very well-known computer terminal is the IBM 5250, which displays alphanumeric text in row and column format. In a computing environment 100 with a host 110 and one or more terminals 130 (referred to herein as a host computing environment), a communications controller 120 was typically included to facilitate the communications between the single host 110 and multiple terminals 130. In a host computing environment 100, software applications run on host 110, and display information is transmitted by host 110 via communications controller 120 to terminals 130. In this manner a user sitting at a particular terminal 130 may start an application on host 110, and host 110 will then display an appropriate screen to the user at the appropriate terminal 130. The user may then enter data in response to the displayed screen, if required.
A host computer and its dumb terminals communicate using an architected data stream that determines the action to be taken when certain characters are transmitted back and forth. When the user desires to perform a task or transaction, the user inputs the appropriate information on the screen to start the task, and presses the enter key to send this information to the host in a data stream. The host takes the information, processes the information appropriately, returns data to the dumb terminal in a data stream (that is typically displayed on the screen), and then unlocks the keyboard for further input by the user.
Determining the user-perceived response time in a host computing environment is relatively straightforward by monitoring the data stream between the host and the terminals. The communications controller 120 monitors the data stream to determine when and how to pass the data between host 110 and terminals 130. As a result, integrating a response time measurement mechanism 160 into communications controller 120 is relatively straightforward. Response time measurement mechanism 160 includes a response time collector 140 and a response time list 150. A response time collector 140 determines the user-perceived response time, and stores this information in a response time list 150. The response time collector 140 starts a timer when the user presses the "Enter" key on his or her terminal, and stops the timer when host 110 sends the "keyboard unlock" message back to that terminal. Response time collector 140 then stores the response time in response time list 150. The contents of response time list 150 may be accessed by host 110 as needed. Response time monitoring mechanism 160 thus provides a simple way to accurately determine the user-perceived response time in a host computing environment 100. However, determining the user-perceived response time in a network computer environment presents greater challenges.
The widespread proliferation of computers prompted the development of computer networks that allow computers to communicate with each other. With the introduction of the personal computer (PC), computing became accessible to large numbers of people. Networks for personal computers were developed that allow individual users to communicate with each other. In this manner, a large number of people within a company, for example, could communicate at the same time with a software application running on one computer system. A computing system that includes multiple computers communicating over a network is generically referred to herein as a network computing environment. One example of a suitable network computing environment 200 is shown in FIG. 2, and includes a server computer system 210 communicating over a network with multiple clients 230.
Today, computer networks are ubiquitous, and great time and effort is being expended to increase the performance of computer networks. One aspect of performance is the user-perceived response time. However, with computers in a network computing environment, known network protocols do not provide any uniform mechanism for determining user-perceived response time. So important are user-perceived response times that some consultants are now basing their fees on the improvement in user-perceived response times they are able to achieve. Therefore, measurement of user-perceived response time is critically important. The problem of accurately measuring user-perceived response time in a network computing environment is complicated by the fact that multiple computers on the network may process sub-parts of a task or transaction in parallel, so the different computers that perform the various sub-tasks will not know when the entire task or transaction is complete. The focus of response time measurements in a network computing environment have been on measuring transaction times. Transaction time is the time required for a transaction to go from start to finish, regardless of how the various steps are accomplished. For the discussion herein, the term transaction time is understood to be the user-perceived response time.
One possible solution to monitoring user-perceived response time is illustrated in FIG. 2, and would place a response time measurement mechanism 260 in the server computer system 210. Response time measurement mechanism 260 could have a response time collector 240 and a response time list 250. Response time collector 240 would actively monitor and interrogate each client 230 to determine response times, and would store these response times in response time list 250. This solution, however, takes considerable processing power and excessive overhead, which would significantly degrade system performance. For this reason, this solution has not been implemented in large-scale networks.
The prior art methods of measuring response time in a network computing environment have excessive overhead, and are not easily implemented. Therefore, there existed a need to provide a response time monitoring mechanism that efficiently collects response times in a network computing environment without introducing excessive overhead.